During 2 years, my packaging efforts were sponsored by eNovance. It has been great to work with them, and I would like to thank them for what they did.
However (for a number of reasons which I don t really think is appropriate to write in this blog), I decided to join Mirantis. This is a formal public announce of it: I will be working from Mirantis office in Grenoble just right after the Paris OpenStack summit of this first week of November.
This is just a quick announce: Debian packages for Juno are out. In fact, they were ready the day of the release, on the 16th of October. I uploaded it all (to Experimental) the same day, literally a few hours after the final released was git tagged. But I had no time to announce it.
This week-end, I took the time to do an Ubuntu Trusty port, which I also publish (it s just a mater of rebuilding all, and it should work out of the box). Here are the backports repositories. For Wheezy:
deb http://archive.gplhost.com/debian juno-backports main
deb http://archive.gplhost.com/debian juno main
For trusty:
deb http://archive.gplhost.com/debian trusty-juno-backports main
But of course, everything is also available directly in Debian. Since Sid/Jessie contains OpenStack Icehouse (which has more chance to receive long enough security support), and it will be like this until Jessie is released. So I have uploaded all of Juno into Debian Experimental. This shows on the OpenStack qa page (you may also notice that the team is nearly reaching 200 packages though am planning to off-load some of that to the Python module team, when the migration to Git will be finished). On the QA page, you may also see that I uploaded all of the last Icehouse point release to Sid, and that all packages migrated to Jessie. There s only a few minor issues with some Python modules which I fixed, that haven t migrated to Jessie yet.
I can already tell that all packages can be installed without an issue, and that I know Horizon at least works as expected. But I didn t have time to test it all just yet. I m currently working on doing even more installation automation at the package level (by providing some OVS bridging init script and such, to make it more easy to run Tempest functional testing). I ll post more about this when it s ready.
I decided I d post this monthly. It may be a bit boring, sorry, but I think it s a nice thing to have this public. The log starts on the 6th, because on the 4th I was back from Debconf (after a day in San Francisco, plus 20 hours of traveling and 15 hours of time gap). It is to be noted that every time something is uploaded in Debian for Icehouse (in Sid), or for Juno (in Experimental), there s also a corresponding backport produced for Wheezy.
Saturday 6th & Sunday 7th:
The annual Debian developer meeting took place in Portland, Oregon, 23 to 31
August 2014. DebConf14 attendees
participated in talks, discussions, workshops and programming sessions. Video
teams captured a lot of the main talks and discussions for streaming for
interactive attendees and for the Debian video
archive.
Between the video, presentations, and handouts the coverage came from the
attendees in blogs, posts, and project updates. We ve gathered a few articles
for your reading pleasure:
Gregor Herrmann and a few members of the Debian Perl group had an informal unofficial
pkg-perl micro-sprint and were very productive.
Vincent Sanders shared
an inspired gift in the form of a plaque given to Russ Allbery in thanks
for his tireless work of keeping sanity in the Debian mailing lists. Pictures
of the plaque and design scheme are linked in the post. Vincent also shared
his experiences of the conference and hopes the organisers have recovered.
Noah Meyerhans adventuring to Debian by
train, (Inter)netted some interesting IPv6 data for future road and
railwarriors.
Hideki Yamane sent a gentle
reminder for English speakers to speak more slowly.
Daniel Pocock posted of GSoC talks at
DebConf14, highlights include the Java Project Dependency Builder and the
WebRTC JSCommunicator.
Thomas Goirand gives us some insight into a working task list of accomplishments and projects
he was able to complete at DebConf14, from the OpenStack discussion to tasksel
talks, and completion of some things started last year at DebConf13.
Antonio Terceiro blogged
about debci and the Debian Continuous Integration project, Ruby, Redmine, and
Noosfero. His post also shares the atmosphere of being able to interact
directly with peers once a year.
Stefano Zacchiroli blogged
about a talk
he did on debsources which now has
its own HACKING
file.
Juliana Louback penned: DebConf
2014 and How I Became a Debian Contributor.
Elizabeth Krumbach Joseph s in-depth summary of
DebConf14 is a great read. She discussed Debian Validation & CI, debci
and the Continuous Integration project, Automated Validation in Debian using
LAVA, and Outsourcing webapp maintenance.
Lucas Nussbaum by way of a blog post releases the
very first version of Debian Trivia modelled after the TCP/IP Drinking Game.
Fran ois Marier s shares additional information and further discussion on Outsourcing
your webapp maintenance to Debian.
Joachim
Breitner gave a talk
on Haskell and Debian, created a new tool for binNMUs for Haskell packages
which runs via cron job. The output is available for Haskell and
for OCaml,
and he still had a small amount of time to go dancing.
Jaldhar Harshad Vyas was not able to attend DebConf this year, but he did tune
in to the videos made available by the video team and gives an insightful
viewpoint to what was being seen.
J r my Bobbio posted
about Reproducible builds in Debian in his recap of DebConf14. One of the
topics at hand involved defining a canonical path where packages must be built
and a BOF discussion on reproducible builds from where the conversation moved
to discussions in both Octave and Groff.
New helpers dh_fixmtimes
and dh_genbuildinfo
were added to BTS. The .buildinfo
format has been specified on the wiki and reviewed. Lots of work is being done
in the project, interested parties can help with the TODO
list or join the new IRC channel #debian-reproducible on irc.debian.org.
Steve McIntyre posted a Summary from
the d-i / debian-cd BoF at DC14, with some of the session
video available online. Current jessie D-I needs some help with the
testing on less common architectures and languages, and release scheduling
could be improved. Future plans: Switching to a GUI by default for jessie,
a default desktop and desktop choice, artwork, bug fixes and new architecture
support. debian-cd: Things are working well. Improvement discussions are on
selecting which images to make I.E. netinst, DVD, et al., debian-cd in
progress with http download support, Regular live test builds, Other
discussions and questions revolve around which ARM platforms to support,
specially-designed images, multi-arch CDs, and cloud-init based images. There
is also a call for help as the team needs help with testing, bug-handling, and
translations.
Holger Levsen reports on feedback
about the feedback from his LTS talk
at DebConf14. LTS has been perceived well, fits a demand, and people are
expecting it to continue; however, this is not without a few issues as Holger
explains in greater detail the lacking gatekeeper mechanisms, and how
contributions are needed from finance to
uploads. In other news the security-tracker
is now fixed to know about old stable. Time is short for that fix as once
jessie is released the tracker will need to support stable, oldstable which
will be wheezy, and oldoldstable.
Jonathan McDowell s summary
of DebConf14 includes a fair perspective of the host city and the benefits of
planning of a good DebConf14 location. He also talks about the need for
facetime in the Debian project as it correlates with and improves everyone s
ability to work together. DebConf14 also provided the chance to set up a hard
time frame for removing
older 1024 bit keys from Debian keyrings.
Steve McIntyre posted a Summary from
the State of the ARM BoF at DebConf14 with updates on the 3 current
ports armel, armhf and arm64. armel which targets the ARM EABI soft-float
ARMv4t processor may eventually be going away, while armhf which targets the
ARM EABI hard-float ARMv7 is doing well as the cross-distro standard. Debian
is has moved to a single armmp kernel flavour using Device Tree Blobs and
should be able to run on a large range of ARMv7 hardware. The arm64 port
recently entered the main archive and it is hoped to release with jessie with
2 official builds hosted at ARM. There is talk of laptop development with an
arm64 CPU. Buildds and hardware are mentioned with acknowledgements for
donated new machines, Banana Pi boards, and software by way of ARM s DS-5 Development Studio - free for all Debian
Developers. Help is needed! Join #debian-arm on irc.debian.org and/or the
debian-arm mailing list.
There is an upcoming Mini-DebConf in
November 2014 hosted by ARM in Cambridge, UK.
Tianon Gravi posted
about the atmosphere and contrast between an average conference and a DebConf.
Joseph Bisch posted about meeting his GSOC mentors, attending and contributing
to a keysigning event and did some work on debmetrics which is powering metrics.debian.net. Debmetrics provides
a uniform interface for adding, updating, and viewing various metrics
concerning Debian.
Harlan Lieberman-Berg s DebConf Retrospective
shared the feel of DebConf, and detailed some of the work on debugging a build
failure, work with the pkg-perl team on a few uploads, and work on
a javascript slowdown issue on codeeditor.
Ana Guerrero L pez reflected on Ten
years contributing to Debian.
If you didn t notice, Javascript isn t as simple as it used to be Want to backport the 2 simple javascript libs? No problem. You then just need to backport a bunch of other packages which are build-dependencies (and file #761670, #761672, and #761674 on the way when rebuilding ). Here s the short list:
gyp node-abbrev node-ansi node-ansi-color-table node-archy node-async node-block-stream node-combined-stream node-contextify node-cookie-jar node-cssom node-delayed-stream node-diff node-eyes node-forever-agent node-form-data node-fstream node-fstream-ignore node-github-url-from-git node-glob node-graceful-fs node-gyp node-htmlparser node-inherits node-ini node-jake node-jsdom node-json-stringify-safe node-lockfile node-lru-cache node-marked node-mime node-minimatch node-mkdirp node-mute-stream node-node-uuid node-nopt node-normalize-package-data node-npmlog node-once node-optimist node-osenv node-qs node-queue-async node-read node-read-package-json node-request node-retry node-rimraf node-semver node-sha node-sigmund node-slide node-smash node-tar node-tunnel-agent node-uglify node-underscore node-utilities node-vows node-whic node-which node-wordwrap nodejs npm ruby-ronnYes, that s 66 packages above And of course, backporting some ruby stuff makes sense :)
Before I start a short listing of (some of) the stuff I did during Debconf 14, I d like to say how much I enjoyed everyone there. You guys (all of you, really!) are just awesome, and it s always a real pleasure to see you all, each time.
Anyway, here s a bits of the stuff I did.
1/ packaging of Google Cloud Engine client tools.
Thanks to the presence of Eric and Jimmy, I was able to finish the work I started at Debconf 13 last year. All python modules are packaged and uploaded. Only the final client (the gcloud command line utility) isn t uploaded, even though it s already packaged. The reason is that this client downloads stuff from internet, so I need to get the full, bundled, version of it, to avoid this. Eric gave me the link, I just didn t have time to finish it yet. Though the (unfinished) package is already in the Git in Alioth.
2/ Tasksel talks
We discussed improvements in Tasksel both during the conference, and later (in front of beers ). I was able to add a custom task on a modified version of the Tasksel package for my own use. I volunteered myself for adding a more task option in Tasksel for Jessie+1 because I really would like to see this feature, and nobody raised hand, but honestly, I have no idea how to do it, and therefore, I m not sure I ll be able to do so. We ll see Anyway, before this happen, we must make sure that we know what kind of tasks we want in this more tasks screen, otherwise it d be useless work for nothing. Therefore, I have setup a wiki page. Please edit the page and drop your ideas there. I ve already added entries for desktops and Debian blends, but I m sure there s more that we could add.
3/ Custom Debian CD
I started experimentation on building my own Debian Wheezy CD image (well, DVD, since the resulting image is nearly 2GB). This was fun, but I am still having the issue that the installer fails to install Dash, so the CD is still unusable. I ll try to debug it. Oh I nearly forgot of course , the ISO image aims at including all OpenStack Icehouce packages backported to Wheezy, and the goal was to include the above custom Tasksel task, with an OpenStack proxy node task, and a OpenStack compute task. Let s hope I can figure out what the issue is, and finally release it.
4/ OpenStack talk
Nothing special to say, just watch the video. I hope my talk was interesting enough. Of course, after watching myself, I hate everything I see, and would like to correct so many mistakes, but that s the usual, I guess.
5/ Some RC fixing
Thanks to the nice work of our DPL rebuilding all the archive, I had to fix a couple of FTBFS issues on my own packages. 3 of them have been easy to fix (2 missing build-dependencies which I missed because my automated build environment has them by default, and a unit test failure), I still don t understand what s going on with Ceilometer. I also NMU-ed transmission (switching from 2.82 to 2.84, as upstream had the bugfix, and current maintainer was not responsive) which was the last blocker for the miniupnpc transition to Jessie. After the 5 days delay of the upload, it went in Sid, then migrated to Jessie, together with the miniupnpc library. I also fixed a trivial RC bug with python3-webob.
6/ Python team meeting
It was nice to see everyone, and hopefully, we ll soon implement what we discussed. I hope to start migrating some of my OpenStack dependencies to the team once we move to Git (though please don t expect this to happen before the Juno release, which keeps me very busy these days).
There s probably more stuff which I did during Debconf 14 (hacking or otherwise), but either it s not worth sharing, or I can t remember :)
I spent many, many hours trying to understand why I couldn t have both nova console-log showing me the output of the log, AND have the OpenStack dashboard (eg: horizon) console to work at the same time. Normally, this is done very easily, by passing multiple times the console= parameter to the Linux kernel as follow:
console=tty0 console=ttyS0,115200But it never worked. Always, it s the last console= thing that was taken into account by sysvinit (or, shall I say, bootlogd). Spending hours trying to figure out what would be the correct kernel command to pass didn t help. Then this week-end, by the magic pure chance of being subscribed to the sysvinit bug reports, I have finally found out. We ve had this bug in Debian for more than 10 years: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=181756 And it has the patch! It just feels so lame that the issue has been pending since 2003, and with a patch since 2006, and nobody even tried to have it enter Debian. I tried the Wheezy patch in the above bug report, and then tadaaaaaa! I finally had both the nova console-log (eg: ttyS0) console output, and the interactive tty0 to work on my Debian cloud image. I have produced a fixed version of the sysvinit package for Wheezy, if anyone wants to try it: http://archive.gplhost.com/debian/pool/juno-backports/main/s/sysvinit/ This doesn t only affect only the cloud images use case. Let s say you have a server. If it s a modern server, probably you have IPMI 2.0 on it. While having access through the integrated KVM over IP may be nice, seeing the boot process through the serial console redirection is often a lot more snappy than the (often VNC based) video output, plus it wouldn t require Java. Too often, Java a requirement for these nasty IPMI web interface (that s the case for at least: Dell DRAC, Supermicro IMPI, and HP iLO). Well, it should now be possible to just use ipmitools to debug the server boot process or to go fix stuff in the single user interactive shell, AND keep the normal video output! :) But keeping this fix private doesn t help much. I would really love to get this fixed within Debian. So I have sent the patch (which needed a very small rebase) in the Git repository of sysvinit (see http://deb.li/3YxUD). I of course tested it in Sid too. Though I tested only under a Xen virtual machine, I see no reason why it would work there and not elsewhere. That being said, I would welcome more testing, given the high profile of sysvinit (everyone uses/needs it, and I wouldn t like to carry alone the unhappiness of having no boot log). Please do test it from the sysvinit git, before it s even uploaded to Sid. Also, these days, sysvinit gets often uploaded to Experimental first. It will probably also be the case for version 2.88dsf-56. If it works well and nobody complains about the patch, maybe it d be worth adding it to Wheezy as well (though that decision is of course left to the release team once the fix reaches Jessie).
As I care to have all the Lintian output and warnings, I have this in my ~/.lintianrc:
info=yes display-info=yes display-experimental=yes pedantic=yes show-overrides=yes color=autoSo, by default, my Lintian setup displays all pedantic warnings. However, it s been annoying me with the debian-watch-may-check-gpg-signature, which I don t really care about since 1/ there s never such a PGP stuff upstream, and 2/ I mostly use Git tags from upstream, in which I do check signatures whenever possible (and mostly, if I have upstream s key in my keyring after a key signing party, which happened a few times). The solution? Well, very easy:
sudo sed -i 's/Disable-Tags:/Disable-Tags: debian-watch-may-check-gpg-signature,/' /usr/share/lintian/profiles/debian/main.profileThere s nothing more to it! Of course, you can also create your own profile, with the added benefit that your changes wont be overwritten on next upgrade. But that s overkill if you re alone in the system, and anyway it s damned easy to do the changes again, plus I often reinstall this computer from scratch. With the above, you can of course disable the display of any tag you wish.
I ve done some clean-up in the Debian BTS. The result can be seen in the QA graphs:
The last remaining 6 bugs are only affecting OpenStack Essex (which is what Wheezy ships, and which unfortunately I have not enough time to support properly), and the last one is waiting for FTP masters approval after I added Python 3 support to oslo-config (OpenStack is slowly moving to Python3, and I ve tried to add support to Python3 in the packages as well each time it was possible). Also, the Icehouse packages have passed the tempest tests (a set of functional tests) which we run in our continuous integration system.
As I was doing some triaging, it is possible that some bugs have been closed a bit quickly (like for example the Ceilometer FTBFS which I couldn t reproduce, even with sbuild and cowbuilder), so it is well possible that some more QA work will be needed later on. I m also expecting a new set of patches for supporting Ceph in Nova. I m sure there s issues which we will discover later on, however, it is nice to have this result right after the first Icehouse release of OpenStack.
Next up: testing new components that I uploaded for this release: Trove (DB as a Service), Designate (DNS as a Service), Ironic (Metal as a Service, or cloud computing on bare-metal), and TripleO (OpenStack on OpenStack). I unfortunately know already that TripleO and Tuskar wont really work yet, and that it needs some patches to be sent upstream for it to support Debian correctly (let s work it out for Juno!). So please consider it as a technology preview only. Though Trove, Designate and Ironic are supposed to be in good enough shape, I didn t have the chance to test them more than just installing the packages and checking daemons are running and connected to the various components of OpenStack (eg: database, keystone and RabbitMQ). Please do test them and report bugs in the BTS.
I d like to thanks Gustavo Panizzo & Thomas Bechtold who contributed to this release, and also the folks at eNovance (Emilien, Cyril, Seb ) who provided precious help with the CI and package quality. See you in the Juno Atlanta design summit next week (as hopefully, my plane ticket issue will be soon solved).
The new version of OpenStack is out, and I have just finished uploading it all into Debian Sid. With a total of 38 packages that I uploaded yesterday (which was exhausting!), most, if not all, were only moving from Experimental to Sid with only tiny updates, and this represents the achievement of 6 months of packaging work. The new feature list is impressive, and I would like to highlight some part of it:
Since I have to do a lot of backports for the OpenStack packages in Debian Wheezy, I got tired of doing them by hand. Therefore, I have created a script to automate the task. I m not particularly proud (or ashamed) of that script, but I just want to share it. Probably some fellow readers will happily provide me with enhancements and ideas.
Note that the use of mk-build-deps implies that the equivs package has to be installed. What I do is run this build-backport script within a cowbuilder, to make sure I always have a clean backport environment.
#!/bin/sh
set -e
set -x
PKG_NAME=$ 1
BPO_DISTRO=wheezy-backports
BPO_POSTFIX=bpo70+1
REPO_ROOT=/home/ftp
REPO_DEST=icehouse-backports
if [ whoami = "jenkins" ] ; then
BUILD_ROOT=/var/lib/jenkins/jobs/openstack-pkg-tools/builds/$ BUILD_NUMBER
else
BUILD_ROOT=~/sources
fi
# Get info from packages.debian.org
PKG_INFO_FILE= mktemp -t pkg_info_file.XXXXXX
wget --no-check-certificate -O $ PKG_INFO_FILE http://packages.debian.org/sid/$ PKG_NAME
DEB_VERSION= rmadison $ PKG_NAME grep sid awk ' print $3 '
UPSTREAM_VERSION= echo $ DEB_VERSION cut -d'-' -f1 cut -d":" -f2
DSC_URL= cat $ PKG_INFO_FILE grep dsc cut -d'"' -f2
rm $ PKG_INFO_FILE
# Prepare build folder and go in it
MY_CWD= pwd
rm -rf $ BUILD_ROOT /$PKG_NAME
mkdir -p $ BUILD_ROOT /$PKG_NAME
cd $ BUILD_ROOT /$PKG_NAME
# Download the .dsc and extract it
dget -d -u $ DSC_URL
PKG_SRC_NAME= ls *.dsc cut -d_ -f1
PKG_NAME_FIRST_CHAR= echo $ PKG_SRC_NAME awk ' print substr($0,1,1) '
dpkg-source -x *.dsc
echo "Now running mk-build-deps -i $ PKG_SRC_NAME -$ UPSTREAM_VERSION /debian/control"
mk-build-deps -i $ PKG_SRC_NAME -$ UPSTREAM_VERSION /debian/control
# Build the package as backport using cowbuilder
cd $ PKG_SRC_NAME -$ UPSTREAM_VERSION
dch --bpo -m "Backported for $ BPO_DISTRO ."
dpkg-buildpackage
cd ..
PKG_FINAL_DEST=$ REPO_ROOT /debian/pool/$ REPO_DEST /main/$ PKG_NAME_FIRST_CHAR /$ PKG_SRC_NAME
ssh archive.gplhost.com "mkdir -p $ PKG_FINAL_DEST "
scp *.orig.tar.* *$ DEB_VERSION ~$ BPO_POSTFIX * archive.gplhost.com:$ PKG_FINAL_DEST
Out of laziness, like many, I use WordPress for this blog. I did try others, but was disappointed (after my blog got hacked a few times), so I just use that.
WordPress has a long history of security issues. So upstream decided to preform automatic updates. This would have been a good thing if automatic update didn t completely mess my blog each and every single time.
On my hosting system, PHP scripts have to be chmod +x to be executed. Otherwise, there s a error, and Apache wont execute the PHP script. The same way, an error will happen if a directory is world writable (eg: chmod 777). This is in order to prevent some of the most common hacks: a hacker finds a way to upload a PHP script (often via a feature of the hosted software), and then uses the uploaded script to do nasty things (like installing phishing sites, send spam, you name it ). Checking on these basic unix rights prevents uploaded scripts to be executed, and it s normally a way harder for hackers to find a way to chmod the PHP scripts than it is to just upload it.
Unfortunately, WordPress, on each upgrade, is resetting these unix rights. Someone got to explain to me the reason why it absolutely needs to chmod 777 the hosted folders, and why it wouldn t keep the chmod +x on the php scripts. Direct result? My blog often gets completely broken by these automated updates. And I didn t find a way to disable them (if someone knows, please send me a quick email).
I have reported the bug upstream: https://core.trac.wordpress.org/ticket/27568
This is the 2nd point release of OpenStack Havana (this is the name of the current stable release of OpenStack). It was out on Thursday (US time), and I uploaded it on Friday (Chinese time). Unfortunately, I realized that the latest python-keystoneclient didn t support the token and endpoint command line options, effectively breaking Keystone itself, and all automated endpoint registration in all core packages. So after fixing Keystone and openstack-pkg-tools, I had to re-upload a 2nd Debian release.
However, after this glitch, the packages passed successfully our CI testing suite: my friends at eNovance and I run the tempest functional test suite each time there s this kind of major update, so that we can validate the packages are working as expected. And all went well after the new keystone command line options were fixed in the postinst scripts.
As a side note, I fail to see consistency on deprecating these interfaces. While we still have the old glance index thing in the Glance client (this is really old), keystoneclient just broke backward compatibility, when keystone is quite recent. So, it looks to me that it wasn t a great idea to just remove token and endpoint this way (though I can understand the need of consistency). Hopefully, this will all be fixed anyway, when we move to the unified python-openstackclient command lines instead of per-project clients.
I realized today that the pkg-openstack team now maintains more than 100 packages. This of course includes general purpose Python modules, which probably will move to the Python module team if it one day supports Git (life is too short: I do not wish to learn such a deprecated technology as SVN). Though this is still a lot of packages, and some more are coming: as per the OpenStack TODO list wiki page, Ironic (a replacement for nova-baremetal), TripleO (OpenStack on OpenStack), Tuskar (contols where things are deployed with TripleO) and Designate (DNS as a Service) are already packaged, and I am waiting for the Icehouse (this is the name of the next stable release) beta3 to be out to upload them to Experimental. This is scheduled for the 6th of March. I believe I am currently nearly up-to-date with the current global-requirements.txt (eg: python dependencies of OpenStack), pending a few Python module upgrades, so hopefully, packaging OpenStack Icehouse beta3 will smooth.
This is sad, but no choice, due to the lack of upstream support: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738322
I just hope xenserver-core will work soon in Debian, so we can fix this unfortunate situation.
I thought it would have been smooth, though it wasn t. OpenRC shipped /sbin/rc, which conflicted with the rc shell (an implementation of the AT&T Plan 9 shell), and /sbin/runscript was conflicting with minicom. With the help of upstream authors, /sbin/rc was renamed /sbin/openrc, and /sbin/runscript was renamed /sbin/openrc-run.
However, the main goal is reached: after last summer Google Summer of Code project, and a bit of rework for the ruff edges, OpenRC made it to Debian.
So, if you wish to try OpenRC, which is a direct replacement for sysv-rc, just add the Debian Experimental repository to your sources.list, and do apt-get install openrc . The only issue will be the first reboot, though that should be fine if one manually shuts down every running daemon, and then type what the postinst suggests as command echoed on the screen. Suggestions on how to improve this is welcome. I warmly also welcome more general feedback.
I d like to publicly thank Patrick Lauer, Benda ( ), WIlliam Hubbs, Alexander Vershilov (who are all OpenRC upstreams), Bill Wang who was the GSoC studdent working on OpenRC, Roger Leigh who is the current sysv-init/sysv-rc maintainer, for their help and support when porting OpenRC to Debian. Without them, it wouldn t have been possible.
Peter Reinholdtsen posted an article on planet.debian.org about symplifying init scripts. I don t think that s a good idea. I tried to do that, and then scrapped all my code, because I ve found OpenRC that was doing what I wrote, in a much better way. We shouldn t reivent the wheel, OpenRC is there already!
The point of switching to a new init system is to get rid of huge init scripts. Well, here s an example OpenRC runscript, rewriting /etc/init.d/rsyslog:
#!/sbin/runscript
command=/usr/sbin/rsyslogd
name="enhanced syslogd"
depend()
provide rsyslogd syslog
need $remote_fs $time
Pretty minimalistic to me... For the record, the original sysv-rc script was 126 lines, and the above is just 10 lines.
I have always pretended that OpenRC would be very easy to port to Debian GNU/kFreeBSD. Well, now I stop pretending:
http://youtu.be/zoNoi8BgQjs
This was done within a few hours working with upstream.
Now, next-up: Debian GNU/Hurd. Hoping that porters will volunteer to do the work.
OpenStack upstream was released today. Thanks to the release team and a big up to TTX for his work.
By the time you read this, probably all of my uploads have reached your local Debian mirror.
Please try Havana using either Sid from any Debian mirror, or using the Wheezy backports available here:
deb http://havana.pkgs.enovance.com/debian havana main After upgrading my Sid virtual machine hosting my Jenkins, build after git push stopped working. This is because version 1.503 and above require an auth token for triggering the build. Since it took me some time to search the web, I ve decided to blog about it to save time to other Jenkins users.
Under each project configuration screen, in the Build Triggers section, tick the Trigger builds remotely (e.g., from scripts) option. Then enter a random token (I used a password generator for it). Then in your post-receive hook, use what s below:
wget -q --no-check-certificate https://<jenkins-url>/job/heat/build?token=<your-token> -O -
Next.